CWSerenade Server Configuration

Purpose: CWSerenade runs on multiple servers:

Application server: This server contains the configuration files, reports, documents, and forms, and other settings required to run the CWSerenade application. It also provides the GUI interface for the users. You can have one or more CWSerenade application servers; see Using Multiple CWSerenade Application Servers for configuration recommendations. One of these servers is typically also used as the HornetQ server if you are using HornetQ as your JMS provider; see HornetQ Configuration.

Database server: This server contains the CWSerenade database and any other database that you use to transmit data between CWSerenade and another application, such as CWStore.

CWIntegrate server: This server contains any sites that are used to transfer data between CWSerenade and another system. This server is typically also used as the MQ Server if you are using IBM WebSphere MQ as your JMS provider. See IBM WebSphere MQ Configuration for more information on MQ setup.

In this topic:

Server Configuration Illustration

Using Multiple CWSerenade Application Servers

Setting Up a CWSerenade Test Environment

Server Configuration Illustration

Using Multiple CWSerenade Application Servers

Purpose: You can use multiple CWSerenade application servers that point to the same CWSerenade database. You may wish to use multiple application servers to balance the system load across servers and spread out the number of users across more than one server.

Server recommendations: MICROS recommends that certain jobs run on separate servers.

Server 1: Dedicate one application server to running the async jobs, integration layer processes, and e-commerce jobs. Also, use this application server to run miscellaneous jobs used for reporting. If you wish to schedule any of these jobs, schedule them to run on this server; see Scheduling Jobs for more information on how to schedule a job.

Server 2: Dedicate one application server to long running batch jobs, such as pick slip generation, memberships, and deposits. If you wish to schedule any of these jobs, schedule them to run on this server; see Scheduling Jobs for more information on how to schedule a job.

Server 3: Dedicate a separate application server to highly interactive jobs, such as Order Entry. Typically, this application server is not used for scheduling jobs. Note: Based on your number of users and transaction volume, you may have more than one application server devoted to highly interactive jobs. MICROS recommends a separate application server for every 30 order entry operators.

Self-contained or shared files? You can configure your application servers to be either self-contained, or to share configuration files, etc. that are stored on one of the application servers.

Self-Contained Application Servers

Shared Application Servers

Updating a properties/configuration file: When you change a properties file or other configuration file, you must restart CWSerenade before the change takes effect; see Restarting CWSerenade for instructions.

In addition, if you use multiple application servers:

• If you use multiple self-contained CWSerenade application servers, you need to maintain the properties file on each application server. The Manifest Properties file must be maintained on the application server that communicates with the manifesting station. See Self-Contained Application Servers.

• If you use multiple shared CWSerenade application servers, you need to maintain the properties file on the primary application server. The Manifest Properties file must be maintained on the application server that communicates with the manifesting station. See Shared Application Servers and Special Setup for Shared Application Servers.

Self-Contained Application Servers

When you use multiple application servers that are self-contained:

• Any configuration files, such as the CWSerenade properties files, must be duplicated on each application server.

• Non-database items, such as reports, documents, and forms, that are generated on one application server, are not accessible from a different application server. For example, if a user clicks on a document on the Document Management screen that is not stored on the application server that the user is connected to, the user will not be able to view the document.

If an application server fails: If an application server goes down, you can have users that were logged into that application server log into another application server that is still running until the other application server is brought back up. To do this, change the user’s URL to point to the other application server, where APP1 is the name or IP address of the application server and 8080 is the port number: http://APP1:8080//CWSerenade.html.

Self-Contained Application Server Illustration:

Shared Application Servers

When you use multiple application servers that share configuration settings:

• Any configuration files, such as the CWSerenade properties files, are stored on one server. This server can be a separate server from any of the actual application servers running CWSerenade or it can be one of the actual application servers.

Configuration server: If the server that holds the configuration files is a server separate from any of the actual application servers running CWSerenade, the configuration files must be stored on a shared network drive.

Primary/Secondary servers: If the server that holds the configuration files is one of the application servers, the system considers this application server the primary application server and the other application servers the secondary application servers. The configuration files are stored on a local drive on the primary application server and the secondary application servers use a shared drive to point to the configuration files on the primary applications server.

• Non-database items, such as reports, documents, and forms, that are generated on one application server, are accessible from a different application server.

If an application server fails:

Configuration server setup: If you use a separate configuration server and one of the application servers goes down, all of the other application servers are able to remain up and operational. If the configuration server goes down, users will not be able to access CWSerenade until the configuration server is back up, or until you configure another server to be the configuration server. Important: If you did not create a backup copy of the configuration server, you will have lost the configuration setup that was on that server. See Saving a Backup Copy of CWSerenade for instructions.

Primary/secondary server setup:

• If a secondary application server goes down, you can have users that were logged into the secondary application server log into another application server that is still running until the other application server is brought back up. To do this, change the user’s URL to point to the other application server, where APP1 is the name or IP address of the application server and 8080 is the port number: http://APP1:8080//CWSerenade.html.

• If the primary application server goes down, users will not be able to access CWSerenade until the primary application server is brought back up. If the primary application server is unrecoverable, you will need to reconfigure one of the other application servers as the primary application server and point the remaining application servers to the new primary application server. Important: If you did not create a backup copy of the primary application server, you will have lost any data that was on that server. See Saving a Backup Copy of CWSerenade for instructions.

Configuration Server/Application Server Illustration:

Primary/Secondary Application Server Illustration:

Special Setup for Shared Application Servers

Jenasys Properties File

CWDirectCP Properties File

Logging Properties File

Encryption Properties File

Jenasys Properties File

Setting

Description

config.dir

The directory on the CWSerenade application server where the system stores the server run-time data.

The delivered setting is C:/Serenade/CWSerenade.

If You Use Multiple Application Servers

Configuration server or primary application server: This is a shared directory on the local drive.

Secondary application server: This is a mapped directory that points to the configuration server or primary application server’s drive. For example: //APP1/Serenade/CWSerenade, where APP1 is the configuration server or primary application server’s name or IP address.

For more information: See Jenasys Properties File for more information on the additional settings in this file.

CWDirectCP Properties File

Setting

Description

CWDIRECTCP_

REPORTS_DIRECTORY

The location on the CWSerenade application server where the system saves a copy of reports.

The delivered directory is C:\\serenade\\CWSerenade\\Forms, where C: is the root drive of the CWSerenade application server.

Note: All backslashes in the directory path must be escaped (doubled \\).

If you Use Multiple Application Servers

Configuration server or primary application server: This is a shared directory on the local drive.

Secondary application server: This is a mapped directory that points to the configuration server or primary application server’s drive. For example: \\\\APP1\\serenade\\CWSerenade\\Forms, where APP1 is the configuration server or primary application server’s name or IP address.

CWDIRECTCP_

DOCUMENTS_

DIRECTORY

The location on the CWSerenade application server where the system saves a copy of any documents (spool files).

The delivered directory is C:\\serenade\\CWSerenade\\Forms\\Documents, where C: is the root drive of the CWSerenade application server.

Note: All backslashes in the directory path must be escaped (doubled \\).

If you Use Multiple Application Servers

Configuration server or primary application server: This is a shared directory on the local drive.

Secondary application server: This is a mapped directory that points to the configuration server or primary application server’s drive. For example: \\\\APP1\\serenade\\CWSerenade\\Forms\\Documents, where APP1 is the configuration server or primary application server’s name or IP address.

CWDIRECTCP_LINK_

TEXT

Defines the text to display on the CWSerenade screens for the link.

Example: If you enter Go To CNN, then each screen will have a link that reads Go To CNN.

If you are Using Multiple Application Servers

If you are using multiple application servers, you will need to update this setting on each server.

CWDIRECTCP_LINK_

URL

Defines the URL to launch when a user clicks the link on a CWSerenade screen.

Example: If you enter http://www.cnn.com, the system opens a new browser window and launches the URL to advance to the CNN website.

If you are Using Multiple Application Servers

If you are using multiple application servers, you will need to update this setting on each server.

For more information: See CWDirectCP Properties File for more information on the additional settings in this file.

Logging Properties File

Setting

Description

CW_LOG_DIR

The directory path on the CWSerenade application server where the logs are located.

The delivered directory is C:\\serenade\\CWSerenade\\Logs, where C: is the root drive of the CWSerenade application server.

Note: All backslashes in the directory path must be escaped (doubled \\).

If you Use Multiple Application Servers

Configuration server or primary application server: This is a shared directory on the local drive.

Secondary application server: This is a mapped directory that points to the configuration server or primary application server’s drive. For example: \\\\APP1\\serenade\\CWSerenade\\Logs, where APP1 is the configuration server or primary application server’s name or IP address.

MQ_FILE_NAME

The name of the log that tracks XMLs and transactional messages generated or received by CWSerenade.

The recommended setting is Message.log.

If you Use Multiple Application Servers

If you use multiple application servers, rename the log so that it identifies the server where the log is located. For example, if you use two applications servers named SERVER1 and SERVER2, rename the Message log on each server to MSGSERVER1.log and MSGSERVER2.log.

APP_FILE_NAME

The name of the log that stores application information.

The delivered setting is APP.log.

If you Use Multiple Application Servers

If you use multiple application servers, rename the log so that it identifies the server where the log is located. For example, if you use two applications servers named SERVER1 and SERVER2, rename the APP log on each server to APPSERVER1.log and APPSERVER2.log.

RESP_FILE_NAME

The name of the log that stores response information.

The delivered setting is RESP.log.

If you Use Multiple Application Servers

If you use multiple application servers, rename the log so that it identifies the server where the log is located. For example, if you use two applications servers named SERVER1 and SERVER2, rename the RESP log on each server to RESPSERVER1.log and RESPSERVER2.log.

TRACE_FILE_NAME

The name of the log that stores trace information.

The delivered setting is TRACE.log.

If you Use Multiple Application Servers

If you use multiple application servers, rename the log so that it identifies the server where the log is located. For example, if you use two applications servers named SERVER1 and SERVER2, rename the TRACE log on each server to TRACESERVER1.log and TRACESERVER2.log.

MANIFEST_FILE_NAME

The name of the log that stores manifesting information.

The delivered setting is MANIFEST.log.

If you Use Multiple Application Servers

If you use multiple application servers, rename the log so that it identifies the server where the log is located. For example, if you use two applications servers named SERVER1 and SERVER2, rename the MANIFEST log on each server to MANIFESTSERVER1.log and MANIFESTSERVER2.log.

ORDER_FILE_NAME

The name of the log that stores order API information.

The delivered setting is ORDER.log.

If you Use Multiple Application Servers

If you use multiple application servers, rename the log so that it identifies the server where the log is located. For example, if you use two application servers named SERVER1 and SERVER2, rename the ORDER log on each server to ORDERSERVER1.log and ORDERSERVER2.log.

PAYPAL_FILE_NAME

The name of the log that stores PayPal transaction information.

The delivered setting is PAYPAL.log.

If you Use Multiple Application Servers

If you use multiple application servers, rename the log so that it identifies the server where the log is located. For example, if you use two application servers named SERVER1 and SERVER2, rename the PAYPAL log on each server to PAYPALSERVER1.log and PAYPALSERVER2.log.

For more information: See Logging Properties File for more information on the additional settings in this file.

Encryption Properties File

Setting

Description

CW_PATH1=

If you are using the CWSerenade encryption routine, the directory path where the encryption key is located.

For example: C:\\EncryptionKey\\. Required if the security level setting is 3 (recommended setting).

Note:

• All backslashes in the directory path must be escaped (doubled \\).

• PCI compliance suggests storing the encryption keys in a location separate from the CWSerenade application server.

• Unlike the example folder location above, you should name the folder where you will store the encryption key a name that does not represent the contents of the file.

The directory path can be a mapped drive on another machine as long as the mapped drive is always connected when the application server is running. For example: \\\\SERVER1\\EncryptionKey\\, where SERVER1 is the server’s name or IP address.

If the folder in the directory path does not exist, you must create it before generating the encryption keys.

CW_PATH2=

If you are using the CWSerenade encryption routine, the directory path where the key encryption key is located.

For example: C:\\KeyEncryptionKey\\. Required if the security level setting is 3 (recommended setting).

Note:

• All backslashes in the directory path must be escaped (doubled \\).

• PCI compliance suggests storing the encryption keys in a location separate from the CWSerenade application server.

• Unlike the example folder location above, you should name the folder where you will store the key encryption key a name that does not represent the contents of the file.

This path is not required if the security level setting is 1.

The directory path can be a mapped drive on another machine as long as the mapped drive is always connected when the application server is running. For example: \\\\SERVER1\\KeyEncryptionKey\\, where SERVER1 is the server’s name or IP address.

If the folder in the directory path does not exist, you must create it before generating the encryption keys.

For more information: See the CWSerenade Data Security and Encryption Reference for more information on how to install credit card encryption.

Email Properties File

Setting

Description

CWEMAIL_

TEMPLATE_PATH

The location of the folder containing the template files used to generate HTML-based emails. The default location is:

C:\\Serenade\\CWSerenade\\EmailTemplates\\

If You Use Multiple Application Servers

Configuration server or primary application server: This is a shared directory on the local drive.

Secondary application server: This is a mapped directory that points to the application server where the email templates reside. For example, where APP1 is the name or IP address of the application server where the email templates reside:

//APP1\\C$\\Serenade\\CWSerenade\\EmailTemplates\\

See Setting up the Email Properties File for more information on the additional settings in this file.

Setting Up a CWSerenade Test Environment

Purpose: To setup a CWSerenade test environment:

Application server: This server contains the configuration files, reports, documents, and forms, and other settings required to run the CWSerenade application. It also provides the GUI interface for the users. This server is typically also used as the HornetQ server if your JMS provider is HornetQ.

For your test environment, you should use a test application server that is separate from your production application servers. By using a separate application server for your production environment and test environment, you can ensure that the configuration files used for production and test remain separate. If your JMS provider is HornetQ, you need to create queues to transmit data between your CWSerenade test environment and another system’s test environment.

Database server: This server contains the CWSerenade database and any other database that you use to transmit data between CWSerenade and another application, such as Xstore.

For your test environment, the CWSerenade database for your test environment can be located on the same server as your production database. Once you create the CWSerenade database for your test environment, you need to update the DBConfig Properties File on the test application server with the new database connection; see CWSerenade Environment Configuration.

CWIntegrate server: This server contains any sites that are used to transfer data between CWSerenade and another system. This server is typically also used as the MQ Server if your JMS provider is IBM WebSphere MQ.

For your test environment, you must create a test site for any CWIntegrate sites that you use to send test data between your test environment and another system’s test environment. If your JMS provider is WebSphere MQ, you need to create queues to transmit data between your CWSerenade test environment and another system’s test environment.

Test Environment Illustration

multiple server setup Serenade 5.0 March 2015